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Jérôme CHAILLOUX 
Octobre 1980 


Notre étude présente la réalisation de rois systèmes (dialecte du 
langage . LISP). développés à l’université de Paris 8 - Vincennes. Ces 
systèmes ont été réalisés : 

- sur miero- processeur à mots de 8 bits (Inte18080/7i Log80) 

- sur mini-ordinateur à mots de 16 bits (PDP11) 

- sur gros ordinateur à mots de 36 bits (PDP10) 


De ces réalisations est extrait un modèle d'implémentation. 


Cette étude propose des solutions aux problèmes de construction et 
d’évaluation de tels systèmes. Ces problèmes sont : 


1) La description exhaustive des imp lémentat ions. 
Nous proposons une description fondée sur la machine référentieile VCMC2. 


2) La représentation adéquate des objets et des fonctions [VLISPI. 
Nous avons associé des propriétés naturelles aux objets dès leur création 
et nous avons établi une typologie fonctionnelle de ces objets. 


3) L’efficacité de l’interprète (en place, en temps d’exécution et en 
compréhension). Notre interprète effectue, pour ses besoins propres, une 
allocation optimale de la mémoire (allocation mesurée en terme d'appels 
du module CONS). L’accès direct (ne nécessitant qu’un accès mémoire) aux 
valeurs des objets de type variable et fonction, et la classification des 
fonctions par types permettent un lancement immédiat de toutes les 
fonctions. La transparence de nos méthodes de description est une 
conséquence naturelle des deux choix précédents. 


4) Le pouvoir des structures de contrôle, 
Notre modèle d’ implémentation généralise les te nee de contrôle de 
VLISF] SELF et ESCAPE en intégrant les nouvelles constructions EXIT, WHERE 
et LETF et en unif liant totalement Leur description et Leur 
implémentation. 


9) La souplesse d'utilisation du système. 
Nous introduisons le nouveau concept de CHRONOLOGIE qui permet de créer 
dynamiquement de nouveaux évaluateurs, permettant Les traces 
méta-circulaires. | 


Une incarnation de notre modèle est donnée dans [CHAILLOUX 801, sous la 


forme de la réalisation d’un système pour la machine référentielle 
VCMC2. 
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1.0 HISTORIQUE CRITIQUE Ez L’ IMPLEMENTATION Da LISP. 


A A a a ra aaa 


Le langage LISP [BERKELEY 74, WEISSMAN 67, ALLEN 78] est aujourd’hui le 
langage le plus utilisé dans les domaines de L’ Intelligence Artificielle 
ININSTON 771 et de la théorie de la programmation INIVAT 791. La 
particularité majeure de LISP est d’avoir pu évoluer de façon naturelle 
depuis sa naissance en 1960 [McCARTHY 60a, 60b]l, à mesure qu’apparaissaient 
de nouveaux besoins. L’échec patent des rares tentatives de 
standardisations {Note 1} a d'une part permis sa survie et d'autre part 
conduit à une amélioration constante du langage tant en efficacité à 
L’interprétation qu’en pouvoir de ses concepts. 


IL en résuite aujourd’hui une floraison d’implémentations, bien loin du 
premier LISP 1 [MCCARTHY 60al, ayant chacune des spécifications 
particulières en fonction de leur utilisation et du moment de leur création. 


On distingue ainsi 4 grandes familles d’ implémentations : 


1) La Lignée LISP 1.5 IMCcCARTHY 621, Descendante directe de LISP 1 qui 
était un système interactif (avec le "FLEXONRITER system"), elle a donné 
le LISP 1.6 [QUAM 721 très proche de LISP 1.5, mais ayant abandonné la 
Liaison par A-liste, décision dont les conséquences ont été monumentales. 
Par la suite, |” importance capitale de l’intégration des instruments ce 
mise au point devint de plus en plus évidente, et LISP 1.8 fut augmenté 
d’un éditeur et d'aides à la mise au point pour donner le U.C.l. LISP 
[BOBROW 73al. 


2) Les systèmes INTERLISP (anciennement BBN LISP) [TEI TELMAN 751 orientés 
sur une utilisation exclusivement interactive, et qui ont donnés 
naissance à des sous-systèmes tels que CLISP [TEITELMAN 731 ou DLISP 
[TEITELMAN 771 qui font une utilisation intensive de périphériques 
interactifs tels les écrans à haute résolution. 


3) MACLISP [MOON 74, LAUBSCH 761 au M.I.T. dont le développement s’est 
réalisé en symbiose avec celui du système MACSYMA [IMACSYMA 731 et qui a 
inspiré la conception de la machine LISP du M.1.T. INEINREB 791. 


4) Enfin les systèmes [VLISP] [GREUSSAY 76a, CHAILLOUX 78a, CHAILLOUX 801 
développés en France à l’Université de Paris 8 - Vincennes, implantés sur 
Les 3 catégories de systèmes matériels (gros, mini et micro) et qui sont 


dotés des structures de contrôle les plus puissantes. 


Le point commun de ces familles d’implémentations est d’avoir toutes une 
réalisation sur l'ordinateur de référence PDP-10 [DEC 78a], qui est la 
machine la plus utilisée dans le cadre des recherches en Intelligence 
Artificielle. Pour cette raison les performances de ces différentes 
réalisations sont aisément mesurables. 


En ptus du PDP-10, ces systèmes LISP n'ont été implantés que sur un nombre 
restreint d'autres matériels en général de taille tres importante tels L’ IBM 
série 360/370 [BOLCE 68, HAFNER 741, L'UNIVAC 1100 ou L*IRIS-50 pour lequel 
on dénombre 3 réalisations en France, le TLISP à l’Université Paul Sabatier 
de TOULOUSE IDURIEUX 781, le RLISP au laboratoire IMAG de GRENOBLE [LUX 78] 


RAA LS 


{Note 1} ces standards sont aussi prématurés qu'arbitraires. Prématurés car 
i1s tombent en désuétude aussitôt créés (voir le standard de [HEARN 69] puis 
[MARTI 79]) et ne tiennent pas compte de l'évolution du langage, arbitraires 
car ils sont essentiellement définis pour satisfaire un programme 
particulier (REDUCE 2 dans le cas de HEARN [BEARN 73, 74]). 
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et SIRLISP à L’E.N.S.T de Paris ICOILLAND 791. 


LISP 1.5 et LISP 1.6, hormis des réalisations-jouets à fins pédagogiques, 
sont à présent tombés en désuétude. 


MACLISP et INTERLISP, trop dépendant de la machine PLP10 (et même du système 
d’exploitation utilisé respectivement ITS et TENEX) n’ont pu être 
transportés dans leur intégralité sur d’autres machines foie 1}. 


Seul, VLISP, (du fait probablement de sa conception en Europe et de la 
diversité des ordinateurs qui y sont disponibles) a pu (ou a dû) être 
réalisé sur un grand nombre de machines très variées telles que CAELSIC 
[GREUSSAY 721, CABS00 INERTZ 741, 11600 IGREUSSAY 751, PDP10 
[CHATLLOUX 76cl, SOLARIG I[GREUSSAY 78b1, 8080 et Z80 ICHAILLOUX /9al et 
PDP11 [GREUSSAY 79bl. 


La diversité de toutes ces réalisations a entrainé la naissance d*histoires 
(et d’historiens) de LISP, apportant de précieuses informations sur 
l’évolution naturelle des langages de programmation (Note 27 [MCCARTHY 78] , 
[WHITE 781, [STOYAN 78a,78bl. 


Les recherches actuelles de construction des systèmes LISP s'élaborent pour 
l’essentiel selon les 4 axes suivants : 


- implémentation sur des ordinateurs universels classiques tel Le VAX-I1 
[DEC /8el ou le S-1 [HAILPERN 79]. 


- implémentation sur des ordinateurs spécialisés, voire des 
micro-ordinateurs, à ressources Limitées [CHAILLOUX 78a, TAFT 791. 


- réalisation de machines spécialisées [GREENBLATT 74, KNIGHT 74, 
SHIMADA 76, LISPMACHINE 77, LECOUFFE 77, TAKI 79, WEINREB 791. 


- apparition d’unités centrales, en technologie  V.L.S.]. [MEAD 801, 
capables d’interpréter directement LISP a une translation près du langage 
source en sa représentation arborescente, dont le répertoire des sommets 
constitue un jeu d'instructions d'interprétation directe de LISP (les 
CHIP-LISP) [STEELE 79, HOLLOWAY 801. 


{Note 1} En date de Septembre 1978, MACLISP ne -tournait encore qu'avec 
beaucoup de difficultés, en ce quí concernait ses aspects-systeme évolués, 
au laboratoire d'Intelligence Artificielle de Stanford, sous système WAITS 
[GREUSSAY 78a]. 


` 


{Note 2} Par opposition aux cas de langages à génération spontanée ou à 
comités [HORNING 79], à définition discrétionnaire. 
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2.0 COMMENT DECRIRE LES IMPLEMENTATIONS la machine VCFCe. 


Des son apparition LISP a été exposé méta-circulairement ¿Note 1} afin 2 
décrire ses propres implémentations. 

Cette utilisation de LISP, très commode, ne satisfaisait pas Les 
implémenteurs experts, qui n'avaient à leur disposition que ces descriptions 
méta-circulaires accompagnées, dans le meilleur des cas, du texte d'une 
implémentation particulière. Tous les problemes réels d’ implémentation en 
machine étaient soit totalement ignorés (dans le cas où LISP était utilisé à 
sa propre descr iption) soit entièrement orientés vers une machine 
particulière. 


Pour illustrer cette situation, nous utiliserons dans cette section, une 
succession progressive de descriptions du module classique EVLIS : nous 
partirons de sa description méta-circulaire en LISP, nous la qualifierons 
sur des machines particulières, enfin nous en donnerons La jeu Li dans 
notre modèle de référence. 2. oo... e a 


Voici la description de la fonction EVLIS, en LISP classique, telle quelle 
est donnée dans les manuels de référence : 


LIS?  eclzssique 


(DE EULIS (L) 
(CONO 
CCNULL L) NIL) 
CT (CONS (EVAL (CAR L)) CEULIS (CIR L))3)3))) 


Une telle description purement méta-circulaire était déjà remise en question 
par John McCARTHY, le créateur du langage : il introduisit deux langages 
LISP, un langage algorithmique (le Méta-langage) qui utilisait des 
M-expressions et un langage de programmation (le LISP tel qu’on le parle 
encore) qui mettait en jeu les S-expressions [McCARTHY 621. Ce double 
Langage permettait de distinguer les données décrites en S-expression des 
programmes décrits sous forme de M-expressions [PERROT 791. 


{Note 1} LISP est spécifiable par un interprète dit méta-circulaire : un 
tel interprète, écrit en [MISP, ramasse en une seule description la 
spécification du langage et celle de l'interprète lui-même {voir Ta 
A de T'évaluateur VMLISF-10 en VLISPI-10 donné dans [CHAILLOUX 78c] 
page 20). 
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PP 


La traduction du langage algorithmique vers le 
automatiquement {Note 1}. 
le langage de programmation a survécu. 


devait s'effectuer 


langage de programmation LISP 
on sait aujourd’hui que seul 


Voici donc la description de la fonction EVLIS en utilisant la notation sous 


forme de M-expressions 


M-expressions 
evlis[li=InullEUISNIL;T>sconstevalicarilld1;evlistedr£t111] 


Si on considère qu'une implémentation particulière constitue une description 
de référence on se heurte aux deux difficultés que sont : 


1) l’opacité inhérente à 


source 


la méconnaissance 


préliminaire de l’ordinateur 


2) la non-généralité chronique de ce type de description. 


Voici donc cette même fonction telle 


machine du PDP10 ICHAILLOUX 780] : 


qu’elle 


est codée dans le langage 


01 EULIS: 


02 JUMPE 
03 HRRZ 
04 PUSH 
05 PUSH) 
06 HLRZ 
07 EXCH 
08 EXCH 
09 POP 
10 CAMGE 
11 JRST 
12 PUSH 
13 PUSH 
14 PUSH 
1 MOVE 1 
16 EULIS1: 
17 HRRZ 
18 MOVEM 
19 PUSHJ 
20 HLRZ 


{Note 1} c'est 
perforatrice de 
M-express?ons. 
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Lengsge machine PDP-10 


A1, UPDPJ 
R2,MEM(AT) 
P, A2 

P, EVALCA 

A1, MECA) 
A1, MEMCFREE) 
FREE, AT 


P,Re 
AT, (A2) 


R2,MEM(CAT) 


P,EVALCA 
A1, MEMCA1) 


des 


Su wr wy wp aus 


caractères spéciaux [, ], et >» 
cartes IBM026 qui a empéché l'utilisation systématique des 


pas d'argument 


Re e (EDR AT) 


gui est sauvé 
évalue la ière val. 
A1 e (CONS A1) 


récupere le reste 
au moins 2 ? 

non : fini 

sauve le ler doublet 
sauve le dernier 
sauve le reste 

Al e les arguments 


Re + (COR A1) 
dans le sommet de la pile 
évalue l'argument suivent 
A1 + (CONS A1) 


sur la 
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| 21 ACH A1, MEM(FREE) | 
| 2 ACH FREE, A | 
| 23 MOUZ A2,-1(P) s £2 < le dernier double | 
| 24 HRRM AT, MEMCAZ) s (RPLECO R2 A1) | 
| 23 MOVE. A1,-1(P) ; Sauva le dernier doublet | 
| 25 {DUE A1, (P) s A1 e le reste | 
| 27 CAML AT, BLIST s il reste des élénents 7 | 
| 28 JRST EUL1S1 ; evi. | 
| 29 sus P,[3,,31 s nen : nettoie la pile. | 
| 39 MOVE A1, 1P) s Al < ter doublet | 
| 31 UFOPJ: | 
| 22 POPJ P, : et voila. | 
| 


Le point 1) est illustré ici par 1? instruction MOVEI, utilisée 
15, qui emploie classiquement la propriété d’adressage suivante 


Ligne 


ee Q+ 
C 
y 


immédiat + indexé = direct 


et permet un gain substanciel de temps : 


Tengs d'exécution des instructions 


MOVE  —A1,A2 1.14 micro-sec 
MOUEI m1, (A2) 0.52 micro-sec 


sur l’unité centrale PDP 10 KI [DEC 78al. 


On notera également la confusion conceptuelle introduite par l’utilisation 
du pointeur de pile P comme registre d’index, pointeur qui ira même (voir la 
Ligne 30) jusqu’à être employé à l'extérieur de la zone pile. 


La non-généralisation de cette description est malheureusement une 
conséquence de l’utilisation raisonnablement experte d’une machine 
particulière. 


Nous devons aller au delà de ces 3 représentations pour aborder, décrire 
correctement, résoudre enfin les véritables problèmes d’ implémentation en 
machine : 


- la représentation en LISP classique montre assez bien l'intention de la 
fonction mais ignore complétement les problèmes d'allocation des 
ressources, souvent limitées, ainsi que la gestion de la récursion. 


- la représentation en M-expressions tout en évoquant approximativement une 
notation algébrique présente les mémes inconvénients que la représentation 
en LISP et introduit un niveau supplémentaire de traduction. 


- la représentation en langage machine PDP10 fait surgir de nouveaux 
problèmes locaux tels que l'accès aux demi-mots de la machine voire 
l’utilisation du pointeur de pile comme registre d’index. La description 
en langage machine est alors supplantée par l'expérience nécessaire à la 
mise en jeu correcte d’adressages et de jeux d’ instructions particuliers. 
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Nous proposons donc de représenter l’ implémentation au moyen de programmes 
d’une machine de référence, la machine VCMC?2, descendante directe de la 
machine VYCMC1 [CHAILLOUX 78b1, et indépendante des représentations internes 
des objets eux-mêmes. C’est de cette description que naissent naturellement 
Les incarnations opérationnelles particulières de sur les ordinateurs 
les plus diversifiés. Cette machine, décrite dans ICHAILLOUX 801, est 
simulée en VEISP+-10 sur ordinateur PDP-10, 


La description de ISF très concise, qui en découle dégage L 
caractéristiques fondamentales de L’ implémentation de modules tels gue EYL 
en machine, l.e. : 


1) les actions de base (test par rapport à NIL, CDR, CONS ... ) 


2) la gestion de la récursion par utilisation d’une pile et d’un 
accumulateur. 


3) le mécanisme du sauvetage et de la restauration du reste de la liste et 
du résultat intermédiaire au travers de la pile. 


4) 1? internalisation totale des fonctions interfaces : entrées/sorties et 


traces (ce que ne pouvait pas faire la notation FILTRE de [GREUSSAY 


Voici donc la description, en VCMC2, de L’implémentation en machine de la 
fonction EVLIS : 


La fonction EULIS décrite en UCNC2 
EULIS: TNIL A1, , [RETURN] 
COR 


A1, TST, ECRLL (EUCAR) 1 
ATOPST A1, , [CALL (EULIS3 1 
CONS TST, AT, [RETURN] 


Cette représentation générale atteint le degré de précision suffisant pour : 


1) appréhender la véritable structure en actions de base de lL’ implémentation 
(ce que ne pouvait pas faire la description d’INTERLISP {Note 1} 


{Note 1} la notation utilisée dans la description de [MOORE 76] ressemble à 
la notation sous forme de M-expressions et ne rend pas compte de la gestion 
de la récursion et des résultats intermédiaires. Sachant que EULIS est le 
version SUBR du module LIST (de type FSUBR) [MOORE 76 pp. 11] ne peut 
décrire cette dernière qu'elliptiquement par le dispositif typographique des 
points de suspension : 


LIST[X1;x2;...xk] 
Return CONS[x1;CONS[x2;...CONS[xk;NIL]...]] 
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2) expliciter totalement la gestion de la pile de récursion en unifiant 


sm coli, 
O 
l’adressage la mise en jeu des accumulateurs et du cache de pile. 


Y 
Ge 


3) indiquer la circulation dans la pile des états d’évaluation 
intermédiaires du contenu initial du registre Al 
4) préciser enfin la structure de contrôle par attachement à 


chanus 
instruction d’une continuation complexe. 
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3.0 EFFICACITE ET PUISSANCE DE L'INTERFRETATION. 


Du fait de sa représentation des objets et des fonctions, notre modèle 
permet de réduire considérablement le temps d’interprétation et de disposer 
d’un grand nombre de structures nouvelles, qui facilitent l'écriture des 
programmes, en améliorent La lisibilité et en diminuent sensiblement la 
taille. 


Voici la définition de La fonction de FIBONACCI utilisée pour des 
comparaisons de vitesse sur plusieurs interprètes LISP fonctionnant sur 


PDP10 : 


(GE FIB (n) 
(COND 
CCZERCP n) 1) 
CEQ n 1) 1) 


CT CPLUS (FIB (SU81 n)3 (FIB (DIFFER n 2)))))) 
(FIB 20) EP 10225 


Voici les temps relevés sur MACLISP, INTERLISP, MISP-10 et MEP-IL Note 2? 
pour le calcul de l'appel (FIB 20) : 


[Temps en secondes] 


MACLISP  INTERLISP — [VLISP-10  [VLISP-11 
48.665 105.78 13.34 35.2 


La rapidité remarquable de l*interprétation de notre modèle est dûe : 


1) à l’utilisation intensive des propriétés naturelles des atomes. et 
principalement du type associé à chaque fonction. Le type d’une fonction 
LISP est déterminé par le langage dans lequel elle est écrite, le mode de 
passage de ses arguments (les arguments sont ou ne sont pas évalués) 
ainsi que le nombre de ses arguments. Cette typologie est abondamment 
décrite dans [CHAILLOUX 80 chapitre 4]. Ce type est directement 
accessible, ce qui permet de réaliser en même temps et le test du type et 
l’appel de la routine associée, au moyen d’un seul branchement indirect 
indexé. En terme de syntaxe, utilise donc l’appel par nom des 


{Note 1} MACLISP utilise dans le cadre de ce test une unité centrale PDP10 
KA-10 et des mémoires à 1.8 micro-secondes [WHITE 76], INTERLISP une unité 
centrale PDP10 KA-10 et des mémoires à 1.0 micro-secondes, NLISP-10 une unité 
centrale PDP10 KI-10 et des mémoires à 1.0 micro-secondes. [MLISP-11 n'a à se 
disposition qu'une micro-unité centrale LSI 11/02. 
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fonctions. 


2) au fait que l” interprete ne réalise plus aucun CONS pour ses besoins 
propres. L*utilisation exclusive d’une pile commune de données et ee 
contrôle évite de créer des structures intermédiaires (sous forme ce 
cellules de liste) durant le processus d'évaluation. Le nombre ae 
récupérations de la mémoire dynamique se trouve ainsi réduit aux seuls 
besoins de l'utilisateur ¿Note 1}. 


3) à l interprétation itérative des fonctions récursives de type NPR et CPR 
[GREUSSAY 76cl. 


4) à l’utilisation des structures de contrôle de MSA qui permettent une 
écriture plus concise et une interprétation plus rapide. En 
particulier : 


- l'opérateur point-fixe du A-calcul [ROBINET 781, représenté par la 
fonction SELF de IGREUSSAY 771 


FIBONACCI se reécrit alors commodément : 


(DE j (n) 


(ZERDP mM 1 
CIF (EOG n 13 1 
(PLUS (SELF (SUB1 n?) 
(SELF (DIFFER n 23333) 


- les fonctions d’échappement ESCAPE. Introduites par  IGREUSSAY 76b1i, 
elles permettent d'associer dynamiquement des fonctions d’ échappement à 
des atomes, réalisant ainsi des sorties non-locales. 


5) enfin à de nouvelles structures de contrôle. Ces nouvelles structures de 
contrôle vont pouvoir réaliser : 


- la description de fonctions anonymes (i.e. qui ne sont pas associées à 
des noms) en utilisant la forme INTERNAL. W 


- Les sorties Locales à une fonction en utilisant la fonction EXIT. 


- la redéfinition dynamique de fonctions de n*importe quel type en 
utilisant la primitive WHERE. 


- la définition d’une nouvelle classe de fonctions, les variables 
fonctions, apportant une solution nouvelle au problème des variables 
internes. 


D SAR e eee RRQ 0 — KA 


{Note 1} La gestion de la mémoire en LISP est automatique et dynamique ce 
gui assure une utilisation optimum de la place mémoire mais oblige à 
construire des modules d'accès et d'allocation (le module CONS) spécialisés 
ainsi qu'un récupérateur de mémoire, dispositif qui ralentit l'interprète. 
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3.1 Descriotion de fonctions anonvmes 


Notre modèle permet de décrire des fonctions anonymes (non associées à des 
symboles atomiques) de n'importe quel type au moyen d’une des deux formes 
INTERNAL suivantes : 


CINTERNSL type edresse-mémnolre) 


CINTERNAL type fonction) 


La première forme permet de décrire des fonctions écrites en langage 
machine, et la seconde des fonctions écrites en |VLISP, 


Ces deux nouvelles formes généralisent l’ancienne utilisation de la forme 
LAMBDA (qui a été gardée par souci de compatibilité et de simplification de 
l’écriture des EXPR anonymes) pour tous les types de fonctions et permettent 
ainsi de Limiter l’utilisation des noms associés aux fonctions. 


Cette Limitation des noms réduit d’autant plus l’espace mémoire nécessaire 
au stockage des symboles atomiques et accroit la Lisibilité du programme qui 
ne contient plus que les noms indispensables. 


3.2 Sorties locales 


La forme EXIT permet de sortir de la dernière fonction invoquée de type 
EXPR, FEXPR ou MACRO. La valeur retournée est évaluée dans l’environnement 
précédant exactement le retour de cette fonction donc évaluée en position 
terminale. Cette propriété est utilisée pour forcer un traitement de 
récursion terminale (Note 1} ce qui n’était pas le cas des fonctions RETURN 
des anciennes formes PROG {Note 2}. 


Voici la méta-description de la fonction MEMBER qui utilise la structure de 
contrôle itérative WHILE. 


ae pq om PP 


{Note 1} Ces appels récursifs terminaux sont interprétés d'une manière 
itérative beaucoup plus efficiente. 


{Note 2} La Forme PROG a été abandonnée dans notre modèle (ainsi que ses 
fonctions associées GO, GOTO et RETURN) car Tes nouvelles fonctions de 
sorties locales et non-locales sont à la fois plus rapides (en effet le 
balayage préliminaire de tous les corps de PROG pour construire la table des 
étiquettes a disparu) et plus générales (avec la possibilité de retourner 
directement d'un nombre quelconque d'appels). 
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(DE MEMBER (a D 
CHILE L 
CIF CESURL (CAR D a) 
(EXIT D 
(NEXTL 03) 


L’appel de la fonction EXIT permet une sortie extraordinaire du KAILE. 


3.3 Définitions dynamiques de fonctions 
La forme WHERE permet de définir dynamiquement de nouvelles fonctions et de 
rendre fluides ¿Note 1} les fonctions el les-máme. 


Voici la syntaxe de cette nouvelle forme : 


| (WHERE Cénon> <fval>) <s1> ... <sN>) 


Le premier argument du WHERE est une définition temporaire d’une fonction 
<fval> associée au nom <non>. Le reste des arguments du WHERE l.e. 
<s1> ... <sN> est un corps dans lequel la définition précédente est active. 
Au sortir du WHERE, la définition associée au nom <nom> disparait et sa 
définition antérieure (s’il en possédait une) est restaurée. 


Voici La fonction de traçage d’une courbe Dragon [GARDNER 67, SCHOETIL 751 
en LOGO-LISP IWERTZ 791 dans laquelle la fonction tourne est redéfinie 
dynamiquement. 

Les fonctions <avance>, <droite> et <gauche> sont des primitives LOGO : 


(DE tourne O (<droite> 95)) 


(DE dragon tn D 
(IF (ZEROP n) 
(<avance> l) 


(WHERE Ctourne '(O0 (<cauche> 20))) 
(dragon (SUBI m 13) 

(tourne) 

(WHERE (tourne '(0 (<droite> SD))) 
(dragon (SUB1 n) 1133) 


A 5 AOO a a 


{Note 1} Une variable fluide est une variable libre liée dynamiquement. 
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3.4 Les variables fonctions 


Notre modèle propose une solution au problème de l’accès aux variables 
internes Note 1} de L’ interprète. En effet, un choix crucial 
d’ implémentation se pose. 

Il n’est que trop tentant d'utiliser des variables VLISP pour accèder à ces 
variables internes. Appelons OBASE la variable interne qui contient à tout 
moment La base de numération des nombres en sortie. Une affectation 
incorrecte de cette variable (par exemple avec une valeur négative), 
détruirait toute possibilité future d’ impression de nombres. 

Une deuxième stratégie consiste à utiliser une fonction associée à chaque 
variable interne. Cette fonction va contrôler La validité des valeurs 
affectées à la variable. C’est ce qu’on entend par. var iabilisation ou 
fonctionnalisation de l'accès. 


oo 


C'est cette dernière stratégie qui a été adoptée dans notre modèie. De plus 
celui-ci propose une nouvelle classe de fonctions, les variables fonctions, 
qui permettent dans une stratégie de fonctionnalisation des variables 
internes de lier dynamiquement les valeurs de ces variables internes, 
retrouvant ainsi toutes les propriétés des variables. 

En lecture ces variables fonctions n’ont pas d'argument et en écriture elles 
possèdent un argument (évalué) qui est la nouvelle valeur de la variable 
fonction. | | 


| ` (variable-fonction) lecture 
| (variable-fonction valeur) écriture 


La nouvelle structure LETF réalise la Liaison dynamique des variables 
fonctions. Elle possède une syntaxe identique à la macro LET : 


(LETF (variable-fonction valeur) corps-du-LETF) 


La 


A —_—_—_ _ 2 


{Note 1} rappelons que ces variables internes sont Tes mots mémoires de 
travail de l'interprète et qu'il est souhaitable que l'utilisateur ait accès 
à certaines de ces variables pour faciliter l'utilisation du système et en 
augmenter la puissance. 
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y 


Cette forme est exécutée en 4 temps : 


1) appel de la variable fonction en lecture (sans argument). 


retournée est conservée. 


2) appel en écriture de la variable fonction avec U argument 


LETP. 


La valeur 


transmis au 


3) exécution en séquence du corps du LETF qui calcule la valeur retournée 


par la forme LETA. 


4) re-appel en écriture de La variable fonction avec en 


ancienne valeur conservée en 1). 


Ce type de Liaison (de même que celle des variables) 


Earn 


argument son 


est réalisée 


2 
automatiguement et en pa rticulier le point 4) est effectuée en cas de sortie 
T 


extraordinaire par un S1 ou un ESCÁFeE enveloppant. 


L'utilisation de ces variables ‘fonctions permet donc d'associer à des 
variables des fonctions qui réalisent des contrôles d’accès dynamigues tant 


en lecture qu’en écriture. 


Voici un exemple d'utilisation de la variable fonction DBASE 


E qui contrôle la 


base de conversion des nombres en sortie. La fonction BRINT-base-x imprime 
son 2ème argument n dans ia base de numération x fournie en ler argument : 


(0EASE K7 10 


(DE FRINT-bsse-x (x n) 
(LETF (OSASE x) 
(PRINT 33) 


(PRINT-kase-x 16 1000) 
(OERSE) KE 10 
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4.0 LA SOLFLESSE D'UTILISATION. 


Un certain type de programmation-systéme consiste à implanter, valider (ou 
invalider), mesurer, modéliser de nouveaux types d’architectures logicielles 
ou matérielles (par simulateur), à la limite de l’élaboration de modèles en 
Intelligence Artificielle. 

Cette programmation se fera tout naturellement dans les conditions les plus 
interactives et les plus expérimentales possibles, et nécessitera des outils 
permettant la réalisation la plus rapide du modèle à valider. Cette 
activité demande donc un langage puissant, très facilement et très 
rapidement mis en oeuvre, car les temps de vie des différents modèles sont 
extrêmement brefs et soumis à des modifications incessantes. 


Ainsi notre système ne mésestime pas l’expertise de ses utilisateurs. IL 
s’agit d’un système utilisable et utilisé, illustrant la nécessité, parfois 
sous-estimée, de ne pas entraver l’expertise raisonnable de ses utilisateurs 
(par exemple en ne l’encombrant pas de contrôles statiques contraignant à 
une programmation médiocre) mais,.tout au.. contraire, de leur . fournir le 
maximum de pouvoir et de souplesse expressive. 


L'utilisation réelle d’une tel système nécessite la faculté de contrôler par 
niveau le fonctionnement de Ll’ interprète, ce qui amène tout naturellement à 
l’idée d*évaluateurs multiples selon les circonstances du calcul. Les 
outils de contrôle de chronologie, traces et erreurs qui vont être décrits 
en sont une illustration. 


4.1 La notion de CHRONOLOGIE 


Notre modèle dispose d’une multitude d’évaluateurs potentiels différenciés 
par un numéro d'ordre de création, un numéro de chronologie. L'accès à 
cette chronologie est réalisée au moyen de la variable fonction CHRONOLOGY. 


Ces évaluateurs peuvent être appelés : 


- par l’utilisateur au moyen de La fonction interprète EVAL dont le deuxième 
argument est le numéro de CHRONOLOGIE que l’on veut voir affecté à cette 
évaluation : 


(EVAL expression chronologie) 


- Soit automatiquement par l’ interprète, il s’agit alors d’interruptions. 
Ces interruptions sont déclenchées par des événements externes (horloges 
ou périphériques) ou par l’interprète lui-même dans les cas suivants : 

- appel de la boucle principale du système (TOPLEVEL) 
- erreur à l’interprétation (ERROR) 

- trace de l’évaluateur (STEPEVAL) 

- ligne pleine en sortie (EOL) 

- apparition d’une fin de fichier d'entrée (EOF) 
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Le traitement d’une interruption se fait par invocation d’une fonction 
propre à chaque type d’interruption, dans un nouvel évaluateur dont la 
chronologie est la chronologie précédente incrémentée d’une unité, l.e. : 


CEURL ‘fonction essoción 


La valeur retournée par la fonction associée à l’interruption devient la 
valeur de l’ interruption. 


IL existe de plus une fonction de sortie extra-chronologie, La fonction 
EXI TCHRENXBLOSY qui réalise la sortie de la chronologie courante et retourne 
une valeur au créateur de cette chronologie. Cette fonction possède la même 
Syntaxe que la fonction de sortie locale à une fonction, la fonction EXIT. 


4,2 Les erreurs 


Notre modèle ne provoque pas l'abandon du travail en cas de détection 
d'erreurs. Lorsqu'il se produit des états d’indétermination dans un 
évaluateur, celui-ci va dynamiquement créer un nouvel évaluateur. Sa ‘tâche 
est de tenter de lever l’indétermination ou tout au moins de retourner une 
valeur à l’évaluateur interrompu. 


Lorsque ces états d’indétermination sont détectés par un interprète (par 
exemple lors d’une consultation d’une variable non définie), une fonction 
spéciale, La fonction ERROR, est automatiquement invoquée avec comme 
arguments les objets indeterminés, dans un évaluateur différent (dont la 
chronologie est égale à la chronologie antérieure incrémentée d’une unité). 
La valeur ramenée par cette invocation est utilisée pour lever 
Ll’indétermination de l’interprète interrompu. 


Cette fonction ERROR (comme toutes les fonctions d’interruptions) peut être 
redéfinie en MI) afin d’utiliser des sytèmes complexes de corrections 
automatiques tel que le système PHENARETE de [WERTZ 781, des outils 
sophistiqués d’aides-à-la mise au point tel que le méta-évaluateur CAN de 
[GOOSSENS 77, 791, des analyseurs [WERTZ 771 des traces ou des steppers 
[GREUSSAY 79al 


Voici un exemple de la redéfinition de la fonction ERROR qui permet de 
construire une fonction testant si une forme peut être évaluée sans erreur 
par EYAL. Dans le cas ou EVAL produirait une erreur cette fonction retourne 
la valeur NIL, et dans le cas contraire elle retourne la valeur de 
l'évaluation. Cette dernière valeur est incluse en premier élément d’une 
liste pour pouvoir distinguer la valeur NIL correspondant à une évaluation 
de cette même valeur indiquant une erreur à l'évaluation. 
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(DE EU2SL-teste-si-erreur {£forme) 
CHAERE (ERROR ‘CO (erreur))) 


(ESCÁSE erreur 
LEVRL forne)1))) 


4.3 Les traces 


Une des facilités majeures de notre modèle est d’avoir un mécanisme interne 
d'observation sélective de l’évaluateur lui-même en fonctionnement. Ce 
mécanisme permet d’appeler la fonction STEPEVAL (qui peut être bien entendu 
redéfinie en MIP) avec comme argument la forme qui doit être évaluée, à 


chague appel interne de l’évaluateur. 


Ce mode trace est activé en donnant une valeur non-NIL au 3ème argument de 
la fonction interprète EVAL : 


CEURL expression chronologie trace) 


Voici comment réaliser une trace de tous Les appels de EVAL. 


(DE TRACEURL (exp) 
(WHERE EN 
CSTEPEURL (forme) 
(PRINT ‘— forme) | 
(SETO IT (EVAL forme (SUB1 (CHRONOLOGY)) T)) 
(PRINT 'e 1) 
(EVAL * (STEPEURL exp) (ADDI C(CHRONOLOGY))))) 


5 Fonction de test : dernier élément de l; 


(DE FCO (1) 
CIF (NULL (COR UD) (CAR O (SELF (CDR D))) 


; Appel de la trace ; 

(TRACEURL * (FOO : (A B))) 

— (FOOD 'CA B)) 

=> (A B) ; 

— (AB) 

—> (IF (NULL (COR 0) (CAR OD (SELF (CDR 00)) 
— 

—} 

—} 


(NULL (CDR 00) 
au $ 
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<< 

¿E 

— Hi 
—> (SELF (COR 0D) 
—> T 1) 


<= {NA B) 
<4 (B) 


—> CIF (RULL (CZAR WU) (CAR OU (SELF (EER 19) 


—> (NULL <(C2A 10) 
— {COR 1) 

> oi 

<— (B) 

— NIL 

¿E 1 

— (DAR OU 

—> l 


Une des difficultés classiques de la réalisation du mécanisme de trace est 
posée par l’ interférence entre la fonction traçante et la fonction tracée en 
particulier en cas d'utilisation des constructions SELF et EXIT : en effet 
dans la llème ligne de trace l'appel (SELF (CDA 1)) doit utiliser la 
fonction tracée (i.e. la fonction FOD) et non pas la dernière fonction 
appelée (i.e. la fonction STEFEURL elle-même). De même l'évaluation d’une 
forme EXIT peut se rapporter soit au programme traçant soit au programme 
tracé. Pour lever toute ambiguité à l'évaluation des formes SELF et EXIT, 
notre modèle utilise la dernière fonction appelée dans la chronologie 
courante. La fonction traçante et la fonction tracée sont évaluées dans des 
chronologies différentes, ce mécanisme permettant également de réaliser des 
traces méta-circulaires {Note 1}. 


Bien entendu des traces plus élaborées (comprenant des renfoncements 
correspondants aux niveaux d’ imbrications des appels ou des numérotations de 
Lignes par niveau et des possibilitées d'exécution incrémentales) peuvent 
étre construites. 


Le fait de pouvoir récupérer TOUS les appels internes de lL’évaluateur 
permet, outre les traces, une modification complete de celui-ci. 


{Note 1} KNUTH [KNUTH 69] propose page 211 l'exercice suivant : 

"6. [40] Design a trace routine which is capable of tracing itseif, in the 
sense of exercice 4; i.e., it should print out the steps of its own program 
et siower speed, and that program will be tracing jitseif at still slower 
speed, ad infinitum until memory capacity is exceeded.” 

Notre mécanisme de trace permet de ne tracer qu'un seul niveau de la 
fonction de trace. 
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Voici en exemple la fonction EVAL-NiL-si-UNDEF qui se comporte comme la 
fonction interprete standard EVAL mais qui ne provoque pas d’erreur à 
l’évaluation d’une variable indéfinie, se contentant uniquement de donner la 
valeur NIL à la variable et d’imprimer un message d'avertissement : 


(DE EUR 


(Coro) 
CIF (Ca (LISTA forme) CNUME? forme) (BOURDE forme)) 
(EVAL formo © T) 
(ERINT “la conne la valeur AIL à :" forma) 
(SET forma NIL33)3) | 
(STEFEVAL expressiom)) 


Voici quelques utilisations de cette fonction en supposant 


que les variables VARFOO1, VARFOO2 et VARFOO3 sont indéfinies 


2 LEVAL-NIL-s i -UNDEF ? USRF001) 
J2 donne la valeur NIL à : VRSFO01 
Er NIL 


? CEVAL-NIL-si-UMIER P'e USRECO2 'B UERFCO31) 
Je conne la vaieur NIL à : USAFCOS 
Ja donne la valeur NIL à VARFCOS 

Ir (ANL B Nil) 


On notera dans cette fonction la redéfinition dynamique de la fonction 
STEPEURL, qui permet de n’effectuer le test de variable indéfinie que dans 
la portée dynamique de La fonction EUAL-NIL-si-UNDEF. 
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Une des caractéristiques les plus importantes de notre modèle est d’être 
très rapidement et très facilement implémenté sur les matériels actuels. 
Trois réalisations récentes montrent la diversité des machines pouvant 
recevoir ce système : 


1) le système MISP-10 ICHAILLOUX 78cl, est réalisé sur L ordinateur 
PDP KI 10 de Digital Equipment Corporation IDEC 78al, sous moniteur 
TOPS10 6.03 IDEC 78bl, SAIL [HARVEY 74, FROST 75] et IRCAM [FROST 771. 
C’est le plus rapide et le plus puissant système existant. Il est 
disponible dans les centres suivants : L’I.R.C.A.M. et le C.I.T.I.2 en 
France, et EDIMBOURG, TURIN et STANFORD SAIL à U étranger. 


2) le système [VLISP-11 [GREUSSAY 79b1, est réalisé sur l’ordinateur PDP 11 
- également de Digital Equipment Corporation [DEC 75] sous système RT11-Y03 
[DEC 78c1. Ce systéme fonctionne actuellement sur les processeurs PDP11 


et sur les micro-processeurs LSI11 [DEC 78d] toujours sous système 
RT11-Y03, 


3) le système VLISP-8 [CHAILLOUX 79al, est concu pour le micro-processeur 
Intel-8080 [INTEL 77al et Zilog-80 [ZILOG 781. IL est disponible sous le 
système de développement ISIS-II [INTEL 77b1 et TRS80 Level II [TRS 781. 


Chacun de ces systèmes représente une catégorie matérielle spécifique : 
gros système pour Le  PDP-10, mini-ordinateur pour Le PDP-11 et 
micro-ordinateur pour le 8080. Les différences entre ces matériels sont 
considérables. Nous évoquerons les points suivants : 


- la taille des mémoires. Le PDP10 permet d’accéder à 256k de 36 bits, le 
PDP11 à 28k de 16 bits {Note 1} et le 8080 à 64k de 8 bits. 


- la vitesse d’exécution des instructions. Le transfert dans un registre 
du contenu d’un mot mémoire demande (indépendemment du nombre de bits 
transférés) 1.06 micro-sec dans un PDP10-KI, 3.2 micro-sec dans un 
PDP11/40 et 4.5 micro-sec dans un 8080-2Mhz. 


- la puissance des instructions. Les jeux d’instructions de ces machines 
n'ont pas la même puissance ce qui amène à utiliser un nombre 
d’intructions plus ou moins grand. Par exemple pour la réalisation de 
l"allocation et de la construction d’un doublet de liste (le module 
CONS), il suffit de 2 instructions du PDP10 (qui occupent chacune un mot 
mémoire de 36 bits) alors qu’il faut un sous-programme de 9 instructions 
pour le PDP11 (chaque instruction nécessite de 1 à 3 mots de 16 bits) 
occupant un total de 12 mots pour L'appel et l’exécution du 
sous-programme. Quant aux performances du 8080 elles sont encore plus 
mauvaises puisqu'il faut Un sous-programme de 21 instructions, qui 
nécessitent chacune de 1 à 3 mots de 8 bits) occupant un total de 30 mots 
mémoire. i 


¿Note 1] ce nombre inhabituel de k mémoire (28k) provient du fait que les 
entrée/sorties sont réalisées en memory mapped I/0 sur 4k mots, qui ajoutés 
aux 28k mémoire conduit bien à un espace adresse de 32k mots. 
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Malgrés leurs différences, il a été possible d’implanter sur toutes ces 
machines un système [WVLISP, tel celui que nous décrire dans cette étude. Les 
différents systèmes ne se différencient que par des vitesses d*exécution e 
des espaces mémoire différents. 


Enfin, le champ d’application du système est extrêmement vaste. Ses 
principales applications récentes recouvrent les domaines suivants : 


- l’amélioration et la correction de programmes avec Le système PHENARETE 


[HERTZ 791. 


- la méta-interprétation de programmes récursifs avec Le système CAN 


[GOOSSENS 791. 
- les algorithmes d'unification IHULLOT 78]. 


- la synthèse de programmes à partir d'exemples avec le système SISP 
[JOUANNAUD 771. 


- la compréhension de programmes avec le système RAINBOW IGREUSSAY 79al. 


- la synthèse d’images colorées telle qu’elle est pratiquée par le groupe 
Art et Informatique de l’Université de Vincennes [AUDOIRE 761, LHUITRIC 
76] 


- l’aide à l'éducation des enfants retardés avec le système LOGO/LIS2 
[HERTZ 791. | | 


- les outils de conception de machines I[ICHAILLOUX 78b, CHAILLOUX 79b1. 
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